cuda.core: add executable graph node updates - #2473

Expose ephemeral graph-node views that update complete executable parameters while retaining every replacement resource CUDA may still use.

Exercise public mutators, rollback, source reclamation, independent ownership, whole updates, and in-flight cleanup end to end.

Three gaps remained around owners attached to an executable graph.

Sequential updates to the same node must keep the superseded owner
reachable, because CUDA cannot detach user objects from an executable;
verified by breaking the append into a replace, which fails the new
test on exactly that assertion.

Closing an executable while a launch is in flight must not retire the
accumulator, since the launch still writes through the buffer that an
individual node update attached.

A child-graph update attaches no owner of its own and relies on CUDA
cloning the replacement graph's user object references into the
executable. Assert that contract directly: the callback outlives the
definition that supplied it and is released with the executable.

CUDA accepts user objects on a CUgraph only, so an executable graph can
never receive an owner after it exists. Document the consequence: one
accumulator is retained on the source graph, propagated by instantiation
or whole-graph update, and then released from the source so the
executable becomes its only owner.

Record why an owner is never removed once appended, and correct the two
Scope entries that still described executable graphs as untracked.

State the retention limit in the release notes as well. The API
reference already documents it, but the note is what a reader sees when
adopting the feature, and retention that looks unbounded deserves the
warning there.

…chments

…chments

Describe how callers use the view rather than how the binding retains
handles or when CUDA validates the node association.

…chments